The power of personal computers, terminals, servers and other stand-alone computing devices is significantly increased by connecting such devices together in a local area network (LAN). Using a network, individual users of stand-alone devices distributed over a large geographic area can access common resources and communicate. Networks themselves can be interconnected or “internetworked” locally or over a large area. Such networks also can be connected to a vast, global network, operating according to standard protocols, known as the Internet. Using the Internet and certain wide area network technologies, local users and devices can connect to, “log on” to, request and use distant devices and computing resources.
For subscriber/service deployment of Digital Subscriber Line (DSL) technologies, wireless, cable, and dial-up access networks, network access aggregation devices 200 (NAADs), as shown in FIG. 1, are used to direct traffic and manage subscribers and services. A user or subscriber 202 is able to simultaneously access the services provided by different Internet Service Providers (ISPs), corporate Layer 2 Tunneling Protocol (L2TP) access servers or any other similar type of servers. A typical NAAD 200 connects at least three different networks—the subscriber's network 202, the subscriber/service management network 204 (SSMN), and the service provider network 206 (SPN). The subscriber's network 202 is the network at which a user, subscriber, host, or client resides. The SSMN 204 is the network at which the subscriber/service management applications 208 (SSMA) resides. The SPN 206 provides the services for the subscribers, such as ISPs 210, application service providers, or corporate access providers. In this scenario, the NAAD 200 regulates the service selection and directs traffic for the subscribers.
The three different networks described above constitute a three-way communication among the parties for a subscriber's service selection. Existing implementations use a simple Host-Key mechanism. In this approach, a subscriber 202 communicates with the SSMA 208 by using Hypertext Transport Protocol (HTTP) via the NAAD 200 to indicate network access requests or service selections. When the NAAD 200 receives a HTTP packet 212, it forwards it to the SSMA 208 through SSMN 204 where the SSMA 208 uses the source Internet Protocol (IP) of the HTTP packet 212 as the Host-Key to identify the subscriber. The SSMA 208 then processes the HTTP packet 212 and communicates the request to the NAAD 200 via a private or management protocol between SSMA 208 and NAAD 200. The Host-Key 214 is carried in the packets of the private or management protocol so that both SSMA 208 and NAAD 200 can use it to identify traffic for the subscriber 202. On the subscriber network 202 side of the NAAD 200, the NAAD 200 uniquely identifies the subscriber 202 and its traffic by the layer 2 characteristic (such as line number, Permanent Virtual Circuit (PVC) input interface, or Media Access Control (MAC), etc.) of the subscriber. However, on the SSMN 204 side of the NAAD 200, the NAAD 200 can only use the Host-Key 214, a layer three entity, to identify the subscriber 202 and the traffic for it since the layer 2 characteristic of the subscriber cannot be preserved across the SSMN 204. This existing practice works fine for most scenarios. However, it has several disadvantages.
The Network Access Providers 216 (NAPs) own the NAAD 200 and SSMA 208 and provides transport and service selection for other service providers. In order for subscribers 202 to subscribe and/or select services at layer 3 by using web-based interface or log on to the access network, they need to communicate with SSMA 208 via NAAD 200 through SSMN 204. For subscribers 202 to access services, they need to communicate through the SPNs 206. Thus, subscribers 202 need to be able to communicate within both SPN 206 and SSMN 204. However, the SPNs 206 and SSMN 204 may not be under the same administrative entity. For example, the SSMN 204 may be administrated by the NAP 216 while the SPNs 206 are administrated by ISPs 210, and both the NAP 216 and ISPs 210 may have totally different IP addressing schemes.
The issues are made more complicated by the fact that ISPs may start using private IP addresses for subscribers and ISPs can no longer afford permanent global IP addresses for the subscribers. Furthermore, NAP may also start using private IP addresses for the SSMN for security reasons or to conserve IP addresses. Thus, this creates a difficult situation for routing a subscriber's traffic and identifying a subscriber.
First of all, when ISPs use the private IP address scheme for subscribers, different subscribers from different ISPs may have the same IP address, since the subscribers' IP addresses are assigned independently by the ISPs. The SSMA has no way to differentiate the two different subscribers by just using their source IP addresses. Thus, the old practice that uses the subscriber's IP address to differentiate subscribers is no longer applicable.
Secondly, when ISPs use the private IP address scheme for subscribers or NAPs use the private IP address scheme for the SSMN, the subscribers' source IP addresses may not be routable in the SSMN. A subscriber's IP address is visible to the SSMN when subscribers make HTTP requests to the SSMA via the NAAD. The SSMN may have difficulty in routing the HTTP replies from the SSMA back to the subscribers since the IP address is not routable in the SSMN. Thus, the old practice that uses the subscriber's IP address for implementing communication between subscribers and the SSMA is no longer applicable.
Thirdly, if global non-overlapped IP addresses are used, the issues of routing HTTP replies and identifying different subscribers are no longer issues for the SSMN and the SSMA. However, in order for the SSMA to communicate with the correct NAAD via the private protocol on behalf of a subscriber, the SSMA has to maintain a table of subscribers' IP addresses that are mapped to the NAADs and the SSMA has to be explicitly configured to service a particular NAAD. This is a huge provisioning problem for both service providers and access providers. This will be even more of a problem as dynamic IP address mechanisms are used.
Fourthly, miss-matching of a subscriber with a NAAD is a possible scenario. If a subscriber, who is connected to one NAAD, tries to log on to the NAAD by accessing a SSMA that is configured to service a different NAAD, the subscriber can be logged on to the different NAAD to which the subscriber has no physical connection. This causes the subscriber's traffic to travel through one NAAD, while the subscriber's information is created in another NAAD (i.e. the SSMA communicates with the wrong NAAD for the subscriber).
Lastly, the old practice that uses the subscriber's IP address to identify the subscriber creates an opportunity for subscribers or hackers to be intentionally or negligently destructive or disruptive to distant systems in many ways. For example, using a technique known as “IP spoofing,” a user can change the IP address in a message sent from the user's computer so that messages or transaction requests sent to a remote network appear to be coming from somewhere else. Therefore, even if the network access devices and an application server are in a common administration zone, it is desirable to indicate a user identity derived from the user's connection to the NAAD to the application servers.
As described above, the use of a subscriber's IP address as identity for the subscriber is no longer meaningful. There is no standard method of allocation for IP addresses, and there is no security in the allocation of IP addresses. The non-secure nature of IP address in IP packed results in IP spoofing.
There are many mechanisms today, which try to do deal with the security issues. One solution is to include a “cookie” whereby data created by a Web server is stored on the user's computer. Cookies provide a way for the Web site to keep track of a user's patterns and preferences and, with the cooperation of the Web browser, to store them on the user's own hard disk. The cookies contain a range of Uniform Resource Locators (URLs) for which they are valid. When the browser encounters those URLs again, it sends those specific cookies to the Web server. For example, a user's identification (ID) is usually stored in a cookie. The cookies would save the user from retyping in the same information all over again when accessing that service for the second and subsequent time.
Another solution is Secure Sockets Layer (SSL). When an SSL session is started, the browser sends its public key to the server so that the server can securely send a secret key to the browser. The browser and server exchange data via secret key encryption during that session.
The problem with each solution, such as the use of cookies or SSL, is that they all rely on information from the user and have no solid connection to the network layer. The relationship between the user and the data packet is not known since the only identity in a data packet is its IP address, which, as discussed above, may be a spoof. Thus, the information which cookies and SSL rely on is non-secure and not reliable. Moreover, cookies and SSL only work for HTTP, the communication protocol used to connect to servers on the World Wide Web. Thus, they are not protocol independent.
Therefore, there exists a need for a more practical and secured mechanism, that is protocol independent, to create an association between a subscriber, a NAAD, and a SSMA.